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REMARKS 

Reconsideration of the rejections set for* in the Office Action is respectfully requested. 
By this amendment, claims 1-2, 4-5, 8-9, 14, 16-21, and 24 have been amended and new clatm 
28 has been presented. Currently, chums 1-5, 8-21, 24-25, and 27-28 are pending in tins 
application. 

ejection to the claims 

The Examiner objected to claims 2 for minor informalities. Applicants have amended 

claim 2 to overcome this objection and request that it be withdrawn. 

T? P .j ^rms under 35 TTSH 102 and 35 USC 103, 

Claims 1-14, 17-20, and 24-25 and 27 were rejected under 35 USC 102 as anticipated by 
Balay (U.S. Patent No. 7,116,665). Claim 15 was rejected under 35 USC 103 as unpatentable 
over Balay in view of Shen (U.S. Patent No. 6,907,039). These rejections are respectfully 
traversed in view of the amendments to the claims and the following arguments. 

This application relates to a way for exchanging routing informaton between differently 
configured YPN sites, so that a VPN site that is using a VR-based VPN model may be 
interconnected with a VPN site that is using a VRF-based VPN model (See Specification at 
page 3, lines 7-10). As described in the background section, there are two commonly used 
mdhod. of establishing VPN tunnels on a network. (Specification at pa.|e 2, lines 8-9). A first 
VPN model is described in IETF RFC 2547, in which VPN routing and forwarding tables 
(VRFs) are used to store routing information. (Specification at page 2, lines 9-17). A second 
VPN model is based on the concept of a Virtual Router (VR). (Specification at page 2, lines 1 8- 
19). A virtual router is often implemented as software construct in a physical router which has 
all the attributes of a physical router, but which shams processor time, switch plane resources, 
and other physical resources of the physical router. (Specification at pag; 2, Lines 19-21). 

As noted by applicants at page 2, lines 27-30, both VR-based VPNs and VRF-based 
VPNs were widely deployed on existing communication networks at the time the application was 
filed. However, because of differences in the way in which they are constructed, the type of 
routing information used by the different models, and the manner in which the routing 
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information was distributed in the different models, it was not easy to h—ect a VPN site 
operating a VRF-based VPN with a VPN site operating a VR based VPN. 

Neither Balay, nor Shen, alone or in combination, teaches a way to interconnect a VR 
based VPN site with a VRF-based VPN site. 

Balay teaches a system that will allow a single VRF to be used to implement mulhple 
VPNs (Balay at Col. 2, lines 39-41). To do this, Balay teaches that multiple VPN Routing and 
Protocol Modules (VRPs) may be created within a VRF (Balay at col. 4, lioes 46-47 "Each VRP 
(eg HI or 112) is associated with a single VPN from the VPN si.e 130")- The VRPs 
associated with the VRF all use" a common FIB and RIB. Each VR? "provides the same 
functional interface to the BGP modules as expected by it from the RIB 113 or FIB 114. The 
VRP (a*. HI or 112), by updating the RJB 113 or FIB 114, enables the VRF 110 to recewe 
VPN data from the CE 131 or the PE backbone 120." (Balay at Col. 4, lines 53-58). 

Thus, it is clear that the VRF in Balay has several VRPs, each of which is associated with 
a separate VPN. The VRPs are not talking to each other and are not allowing information to be 
exchanged between the VPNs. Rather, the purpose of using separate VFPs is to allow mulnple 
VPNs to be supported by a single VRF. This reduces the number o.: VRFs required to be 
implemented by a given PE by allowing, for example, one VRF to be supported per VPN sxte. 
(Balay at Col. 2, lines 35-44). Specifically, Balay realized that a given customer may need to 
have multiple VPNs established. Balay suggested using a single VRF so that a single interface 
channel could be used to connect to the customer's VPN site. Balay further teaches that multiple 
VRPs may be created within the VRF to allow multiple VPNs to be supported to that customer's 
VPN site over the single connection. Thus, Balay proposes a way for a siogle interface to be 
used to support different VPNs from a VPN site. 

In rejecting the claims, the Examiner has taken the position mat Balay teaches 
"processing network traffic between first and second VPN." Applicants respectfully submit that 
this is not how Balay operates. Balay does not transmit traffic between t ie VPNs. Rather, Balay 
implements VRPs specifically to keep the traffic for the different VP Ms separate. Note, that 
Balay teaches that each VRP should be used to support only one VPN Tins allows the traffic 
from that VPN to be separated from traffic from other VPNs that are also using the same VRF. 
If Balay was seeking to transmit traffic between VPNs, Balay wouldn t need to use a separate 
VRPs for each VPN. 
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The Examiner ha* taken the position that Fig. 4 teaches receiving first routing, 
information associated with a first VPN (citing box 410 of Fig. 4) m d men oas taken the postUon 
that Balayteaches receiving second routing information associated with the firs.; VPN (cihng box 
412 of Fig. 4). There are several flaws in this rejection. 

First Fig. 4 of Balay is provided to show how data is being handled by the network 
element in Balay, not to describe how routing information, is being hailed. Since clan* 1 
recites "receding ... first routing information" and "receiving... second routing mformaUon 

Fig 4 is not relevant to the claims. 

Second, Fig. 4 clearly shows that step 410 shows receiving a first packet associated with 
a first VPN, and that step 412 shows receiving a second packet associated with a second VPN. 
Thus Fig. 4 does not show receiving first and second packets that are associated with the same 
VPN. Rather, Fig. 4 shows that the same VRF can receive packets associated with different 
VPNs Thus, for this additional reason, Fig. 4 of Balay is not relevant to cairn 1. 

The first step of claim 1 recites "receiving, by a network device, first routmg . 
information..., the first routing information being associated with a firsl VPN. The Examiner 
has cited Fig. 4 (box 410) and col. 8 lines 5-30 ("receiving a packet at 1he PE node associated 
with the first VPN. At step 420, fig. 4, the first data packet is associated with the first VRP")- 
Balay states, however, at Col. 8 lines 304 that Fig. 4 "illustrates a flow diag-am of one method 
400 for processing network traffic..." Thus, Balay is not using Fig. 4 to show how routing 
information is handled, but rather is using Fig. 4 to show how data is handed. 

The second step of claim 1 recites receiving, by the network device, second routing 
information..., the second routing information also being associated w.th the first VPN. The 
Examiner has taken the position that this is shown by Balay at Fig. 4, step 412. As mentioned 
above, Fig. 4 is showing how data is being handled not how routing information is being 
handled. Moreover, and more fundamentally, the second step of this chdm recites that the 
second routing information is also associated with the first VPN. Box 412 of Balay states that 
the second packet is "Associated with 2 nd VPN" not the first VPN. Thm, tus portion of Balay 
does not support the Examiner's position for this additional reason. 

There is also another reason why Balay does not anticipate clain 1. Specifically, Balay 
does not teach or suggest a VPN implemented using both VR and VRF-based VPN models. 
Claim 1 recites ♦'receiving, by a network device, first routing information from a Virtual Router 
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rn ^ VPN site Mgrnentej aw a VR-based muoadd" (-I*-* adde ^ ^ 
Examiner has not addressed this limitation specifically, and has not explained how the cited 
pcrtions of Balay relate to a VR-hased VPN model. Rather, the Examiner has simply cited Fig. 
4 col 8 lines 5-30- These portions relate to receipt of data packets, and do not menuon a VR- 
b'ased VPN model. Accordingly, for this additional reason, applicants re ip ectfully submit that 

Balay fails to anticipate claim 1, 

Although the arguments have focused on claim 1, the other independent claims are 

likewise patentable over the art of record. 
Conclusion 

Applicants believe the claims as pending or amended are allowable over the art of record. 
However, if the Examiner is not of the same opinion, applicants would be very interested in 
talking with the Examiner to discuss the cited art and the claims to attempt to arrive at claims 
that the Examiner feels are of appropriate scope in view of the prior ait. Accordingly, if the 
Examiner believes that the claims are unpatentable for any reason, the Examiner is invited to 
telephone the undersigned at the telephone number listed below to discuss this application. If the 
Examiner has any questions or concerns regarding the amendments or these remarks, the 
Examiner is also requested to contact the undersigned. 

If any fees are due in connection with this filing, the Commissioner is hereby authorized 

to charge payment of the fees associated with this communication or credit any overpayment to 

Deposit Account No. 502246 (Ref: NN-15942). 

Respe^tfelly Submitted 

Dated: June 17, 2008 ^ l^ £ £i£s£l 

Anderson Gorecki & Manaras, LLP / 

P.O. Box 553 

Carlisle, MA 01741 

Tel: (978) 264-4001 x2337 

Fax: (978) 264-9119 
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